폭포수 모델

3. 모델

폭포수 모델은 소프트웨어 개발에 있어 순차적인 단계를 따르는 방식이다. 각 단계는 이전 단계가 완료되어야만 시작할 수 있다는 특징이 있다.

로이스가 제시한 최초의 폭포수 모델은 다음과 같은 단계를 거친다.^[16]

# 소프트웨어 요구사항 기술

# 소프트웨어 설계

# 소프트웨어 구현

# 시험과 디버깅

# 설치

# 소프트웨어 유지보수

폭포수 모델에서는 요구사항 확정 후 설계, 설계 완료 후 구현과 같이 한 단계씩 순차적으로 진행한다.

그러나 최초 모델과는 달리, 프로세스 일부를 변형한 다양한 수정 모델들이 존재한다. 로이스의 최종 모델도 그중 하나인데, 하류에서 결함이 발견되면 이전 단계로 돌아가거나, 하류 단계가 불충분하면 설계 단계로 돌아가는 변형이 포함될 수 있다.^[8]

폭포수 모델은 이전 단계가 검토 및 검증된 경우에만 다음 단계로 진행하여 공정의 진척 관리가 쉽다는 장점이 있다. IBM의 ADSG(Application Development Standardization Guide, 애플리케이션 개발 표준화 가이드) 등이 폭포수 모델의 예시이다.

"폭포수 모델은 구식이고, 나선형 모델은 새롭다"라고 단순하게 이야기되는 경우도 있지만, 대규모 개발에서는 나선형 모델만으로는 수렴되지 않고 파탄나는 경우가 대부분이기 때문에, 현재도 폭포수 모델과 나선형 모델 등은 조합되어 사용되고 있다.

3. 1. 개발 단계

위와 같이 작업 공정(국면, 페이즈)을 톱다운 방식으로 분할하고, 간트 차트를 사용하여 이러한 공정을 한 번에 완료하는 계획을 세우고 진척 관리를 한다. 원칙적으로 이전 공정이 완료되지 않으면 다음 공정으로 진행하지 않으며, 이전 공정의 성과물의 품질을 단계적으로 확보하고 이전 공정으로의 되돌림(재작업)을 최소화한다.

3. 2. 단계별 진행 방식

4. 사용 사례

폭포수 모델은 미국 국방성이나 NASA 등 대규모 소프트웨어 개발 기관에서 널리 사용되었으며, 그 외 다수의 대규모 정부 프로젝트에서도 사용되었다. 그러나 이 모델을 사용하는 업체나 개발자들은 순수 폭포수 모델과 변형 모델을 명확히 구분하지 않았기 때문에, 실제로 어떤 모델이 사용되었는지 정확히 파악하기는 어렵다.

미 국방성은 1994년의 MIL-STD-498과 1998년의 IEEE 12207을 통해 폭포수 모델의 제약 조건에서 벗어났다.

4. 1. 대한민국 국방부 및 공공기관

5. 관련 논의

폭포수 모델은 소프트웨어 개발 초기 단계에 충분한 시간을 투자하여 생명 주기 후반부에 큰 비용 절감 효과를 가져올 수 있다는 경제적 관점에서 논의된다. 초기 단계(요구사항 기술 또는 설계 단계)에서 발견된 버그는 후기에 발견된 버그에 비해 수정하는 데 드는 시간, 비용, 노력이 훨씬 적게 든다. 스티브 맥코넬은 저서 "Rapid Development"에서 요구사항 결함이 구현이나 유지보수 단계까지 발견되지 않으면, 이를 수정하는 비용이 요구사항 기술 시에 수정하는 것에 비해 50배에서 최대 200배까지 증가할 수 있다고 예측했다.^[17]

프로그램 설계가 구현 불가능한 경우, 설계 단계에서 수정하는 것은 쉽지만, 몇 달 뒤 구현 및 통합 과정에서 발견되면 그때까지 개발된 모든 것을 버려야 할 수도 있다. 이러한 논의는 사전 대규모 설계 (BDUF)와 폭포수 모델의 핵심 아이디어이다. 따라서 폭포수 모델을 따르는 개발자들은 전 단계가 100% 완료되고 정확하다는 것을 확인한 후에 다음 단계로 진행하고자 한다.

폭포수 모델은 문서화를 강조한다는 점에서도 논의된다. 요구사항 기술, 설계, 소스 코드에 대한 정확하고 완벽한 문서화를 통해 팀 구성원이 변경되어도 프로젝트를 지속하는데 어려움이 없도록 한다.

5. 1. 장점

5. 2. 한계

6. 폭포수 모델에 대한 비판

폭포수 모델은 실제 프로젝트에서 각 단계를 완벽하게 완료하고 다음 단계로 진행하는 것이 어렵고, 고객의 요구사항 변화에 유연하게 대처하기 어렵다는 비판을 받는다.

의미 있는 규모의 프로젝트에서는 다음 단계에 대한 이해나 경험 없이 각 단계를 완벽히 마무리하는 것은 불가능하다. 예를 들어, 고객들은 동작하는 프로토타입을 보기 전에는 정확히 자신들이 무엇을 원하는지 요구사항으로 정하지 못할 수 있다.^[21] 또한 고객들은 정해진 요구사항을 빈번하게 수정하기도 하며, 설계자나 구현자가 이를 통제하기는 어렵다. 설계 완료 후 요구사항이 변경되면, 설계는 새로운 요구사항을 반영해야 하고, 이전까지의 노력은 무위로 돌아간다.

설계자들은 설계 시 향후 구현 작업의 난이도를 예측하기 어렵다.^[22] 구현 단계에서 특정 설계의 구현이 불가능하거나 매우 어렵다는 것이 명백해지는 경우가 있을 수 있다. 이 경우, 기존 설계를 유지하기보다 재설계를 하는 것이 더 나은 선택이다.

스티브 맥코넬은 설계나 구현을 끝내기 전에는 완전히 알 수 없는 요구사항이나 제약조건의 문제인 "못된 문제(wicked problem)"를 언급하며, 이 때문에 소프트웨어 개발에서 한 단계만을 완성하는 것은 불가능하고, 폭포수 모델을 사용하는 것도 불가능하다고 지적했다.

데이빗 파나스는 그의 글에서 다음과 같이 썼다.^[33]

> “[시스템의] 세부 사항 중 많은 부분은 우리가 [시스템의] 구현을 진행할 때라야 비로소 우리 눈에 보이기 시작한다. 그리고 그렇게 알게 된 것 중 일부는 우리의 기존 설계를 무효로 만들고, 다시 전 단계로 돌아갈 수밖에 없게 만든다.”

폭포수 모델의 "두 번 검토해보고, 한번 실행하라(measure twice; cut once)."는 격언은, 소프트웨어 요구사항이나 문제 자체가 지속적으로 변화하기 때문에 비현실적이라는 비판을 받는다.

미국 국방부 등 일부 조직은 1994년 MIL-STD-498을 시작으로 폭포수 모델에 반대하며, '진화적 획득'과 ''반복적이고 점진적인 개발''을 장려한다.^[24]

폭포수 모델에 대한 비판은 다음과 같다.

• "폭포수 모델은 잘못되었고 유해하다. 우리는 이 모델에서 벗어나야 한다."
• "폭포수 접근 방식은 위험하고 문제를 안고 있는 기업의 풍토병이다."
• "폭포수 모델은 질서정연하고, 예측 가능하며, 설명이 가능하고, 측정 가능한 프로세스이며, 문서를 중심으로 한 단순한 마일스톤이 존재한다는 환상을 주었다."

6. 1. 비판의 주요 내용

• 전 단계의 실수가 없다는 전제: 폭포수 모델은 이전 단계, 특히 소프트웨어 요구사항 기술 단계에서 실수가 없어야 한다는 것을 전제로 한다. 하지만 현실에서는 요구사항을 사전에 완벽하게 정의하는 것이 매우 어렵다.^[32]
• 요구사항 정의의 어려움: 고객은 실제로 동작하는 소프트웨어를 보기 전까지는 자신이 원하는 바를 정확하게 알지 못하는 경우가 많다. 이로 인해 개발 중간에 요구사항 변경이 빈번하게 발생할 수 있다.^[21]
• 전 단계로의 되돌림 문제: 요구사항 변경이나 설계상의 문제 발견 시, 이전 단계로 돌아가 작업을 다시 해야 하는 경우가 발생한다. 이는 일정 지연의 주요 원인이 된다.^[33]
• 설계 시 구현 난이도 예측의 어려움: 설계 단계에서는 향후 구현 단계에서 발생할 수 있는 어려움을 예측하기 어렵다. 구현 단계에 이르러서야 특정 설계의 구현이 불가능하거나 매우 어렵다는 것이 명백해지는 경우가 있을 수 있다.^[22]

7. 수정 모델들

순수 폭포수 모델의 문제점에 대한 대응으로, 다양한 수정 폭포수 모델이 소개되었다. 이러한 수정 모델은 순수 폭포수 모델의 비판을 일부 또는 전부 해결할 수 있다. 스티브 매코넬의 저서 ''Rapid Developement: 프로젝트 쾌속 개발 전략''에서는 다양한 수정 폭포수 모델을 다루고 있다.^[17]

이러한 모델에는 스티브 매코넬이 "수정된 폭포수"라고 부르는 급속 개발 모델, 피터 드그레이스의 "사시미 모델"(단계가 겹치는 폭포수 모델) 등이 있다. 그 외에도 하위 프로젝트를 포함하는 폭포수 모델, 위험 감소를 위한 폭포수 모델, "점진적 폭포수 모델"과 같이 다른 소프트웨어 개발 모델과의 조합도 존재한다.^[25]

7. 1. 사시미 모델

7. 2. 기타 수정 모델

7. 3. 로이스의 최종 모델

참조

_[1] 서적 Product-Focused Software Process Improvement Springer Science+Business Media |Springer 2009
_[2] 논문 Evolutionary Delivery versus the 'waterfall model'
_[3] 논문 Waterfall Model Springer Science+Business Media |Springer 2013
_[4] 간행물 Designing for knowledge maturing: from knowledge-driven software to supporting the facilitation of knowledge development Association for Computing Machinery |ACM 2014-09-16
_[5] 간행물 Symposium on advanced programming methods for digital computers Office of Naval Research, Dept. of the Navy 1956-06-29
_[6] 논문 Production of Large Computer Programs http://sunset.usc.ed[...] IEEE Educational Activities Department 2011-03-21
_[7] 논문 Iterative and Incremental Development: A Brief History https://www.craiglar[...] 2003-06
_[8] 논문 Managing the Development of Large Software Systems https://www-scf.usc.[...]
_[9] 웹사이트 Waterfall http://www.informati[...]
_[10] 서적 Agile Processes in Software Engineering and Extreme Programming Springer Science+Business Media |Springer 2008
_[11] 웹사이트 Waterfall methodology: there's no such thing! http://www.idinews.c[...]
_[12] 서적 Inheriting Agile: The IT Practitioner's Guide to Managing Software Development in a Post-Agile World https://books.google[...] Sandprint Press 2024-04-25
_[13] 웹사이트 Software requirements: Are they really a problem? http://pdf.aminer.or[...] IEEE Computer Society Press
_[14] 서적 DOD-STD-2167 - Military Standard : Defence System Software Development" Department of Defence, United States of America 1985-06-04
_[15] 웹사이트 Military Standard Defense System Software Development http://www.product-l[...]
_[16] 서적 Inheriting Agile: The IT Practitioner's Guide to Managing Software Development in a Post-Agile World https://books.google[...] Sandprint Press 2024-04-25
_[17] 서적 Rapid Development: Taming Wild Software Schedules https://archive.org/[...] Microsoft Press
_[18] 웹사이트 Waterfall Software Development Model http://www.oxagile.c[...] 2014-08-11
_[19] 뉴스 Tutorial: The Software Development Life Cycle (SDLC) http://softwarelifec[...] 2012-11-13
_[20] 웹사이트 Comparing Traditional Systems Analysis and Design with Agile Methodologies http://www.umsl.edu/[...] University of Missouri – St. Louis 2009
_[21] 논문 A rational design process: How and why to fake it https://www.cs.tufts[...] 2011-03-21
_[22] 서적 Code Complete, 2nd edition https://archive.org/[...] Microsoft Press
_[23] 서적 The Computer Boys Take Over https://archive.org/[...] MIT Press
_[24] 논문 Iterative and Incremental Development: A Brief History http://doi.ieeecompu[...]
_[25] 웹사이트 Methodology:design methods http://myprojects.ko[...]
_[26] 논문 From Waterfall to Agile software: Development models in the IT sector, 2006 to 2018. Impacts on company management https://www.ceeol.co[...] Fundacja Centrum Badań Socjologicznych 2023-09-28
_[27] 논문 (PDF) Software Engineering Methodologies: A Review of the Waterfall Model and Object- Oriented Approach https://www.research[...] IJSER Publishing 2023-09-28
_[28] 서적 Product-Focused Software Process Improvement Springer 2009
_[29] 웹사이트 The Traditional Waterfall Approach https://www.umsl.edu[...] 2022-02-23
_[30] 논문 Production of Large Computer Programs http://sunset.usc.ed[...] IEEE Educational Activities Department 2011-03-21
_[31] 웹사이트 Wasserfallmodell > Entstehungskontext http://cartoon.iguw.[...] Institut für Gestaltungs- und Wirkungsforschung, TU-Wien
_[32] 웹사이트 Managing the Development of Large Software Systems http://www.cs.umd.ed[...]
_[33] 웹사이트 A Rational Design Process: How and Why to Fake It http://web.cs.wpi.ed[...]